Awesome! I like the message, as is. However if you want to shorten it one option would be to link the discussion in your other PR.

Interesting, I wonder how this is causing failures on v1.6

yikes, I think we should then drop the hint on v1.6.

Great! Both for this specific hint itself, and for setting the precedent :)
I can easily see more error hints added to Accessors over time to make errors clearer.

Maybe, in the future we should turn methods that exist only to show user-friendly errors into error hints (eg

Maybe, in the future we should turn methods that exist only to show user-friendly errors into error hints (eg

What are the pros and cons for having an error hint vs a detailed error message?

What are the pros and cons for having an error hint vs a detailed error message?

Don't know for certain, separation of concerns maybe?
Even in this specific example, one could easily make it an extra method throwing an error. Same as with Base hints like string + string or max(vector).

Don't know for certain, separation of concerns maybe?

Mhh which concerns are separated here?

One problem with defining a method and then making it error is that it makes interactively exploring an API (or just trying to look-before-you-leap) less reliable.

e.g. if we did

insert(v, ::DynamicIndexLens, x)  = error("...")

then someone might do hasmethod(insert, ...) and get true, or to look at the list of methods(insert) and then think from that that the method is callable.

Mhh which concerns are separated here?

One is "arguments for the function are wrong" (then throw an error), another is "here's what you could do if we guess your intent correctly" (show an errorhint).

One other reason that it's good to use error hints here rather than defining an error method is that defining error methods can cause method ambiguities. For example, if someone else defined the method

insert(::MyType, ::Any, ::Any) = ...

then it might end up being ambiguous with

insert(::Any, ::DynamicIndexLens, ::Any) = error("...")

even though the conflicting method is just a junk method we created to try and give more informative error messages

Looks like the v1.6 failure is unrelated?

Weird, it definitely passes on master.

Aaah, I see! There's another __init__ defined above :) And your method overwrites it.

Silly me.

An alternative design we could do here is something like this:

That keeps the hint small, but lets users interactively access the full error hint (it'd also let us drop the Markdown dependency, since docstrings handle markdown for us already)

I think it's better to avoid overengineering, and keep a single message in a single place.

As I understand, @jw3126 also likes the PR in its current state, so going to merge.
And looking forward for the bright future with understandable error messages :)

What are the pros and cons for having an error hint vs a detailed error message?

Oh, I think an even more concrete pro of an error hint is that it goes in addition to the actual error message – not replaces it.

Currently:

julia> @set f((a=1,b=2)) = 3
ERROR: This should be unreachable. You probably need to overload
`Accessors.set(obj, ::typeof(f), val)

Potentially without error() but with a hint with the same message:

julia> @set f((a=1,b=2)) = 3
ERROR: MethodError: no method matching _set(::@NamedTuple{a::Int64, b::Int64}, ::typeof(f), ::Int64, ::Accessors.SetBased)

You probably need to overload `Accessors.set(obj, ::typeof(f), val)

Closest candidates are:
  _set(::Any, ::Any, ::Any, ::Accessors.ModifyBased)
   @ Accessors ~/.julia/dev/Accessors/src/optics.jl:187
  _set(::Any, ::ComposedFunction, ::Any, ::Accessors.SetBased)
   @ Accessors ~/.julia/dev/Accessors/src/optics.jl:191

It shows the same suggestion, but also prints which specific method was not found (ie what type obj and val are), and closest candidates. The latter isn't really useful in this specific case, because the function _set is an internal one.
Actually, I don't know why OpticStyle/_set/_modify are needed at all. Is it just because Julia doesn't compile efficiently otherwise, or for some fundamental reasons?

I don't know why OpticStyle/_set/_modify are needed at all. Is it just because Julia doesn't compile efficiently otherwise, or for some fundamental reasons?

These were needed a long time ago for inference reasons, which may no longer apply I guess.